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Markierung der mit diesem Element verknupften Signal im 
zwezten Teiibereich des Anzeigemittels vorgesehen. Die grafi- 
DeT D " S : ellUn9 ^-tiert sich somit an ublichen Software- 
Debug-Kerkzeugen. Der Programmverlaur kann durch eine Markie- 
rung eznes Elements des Listings des Programs verfolgt we" 
den. in zwezten Teiibereich des Anzeigemitteis bewegt sich 
ezne Markzerung synchronisiert zur Markierung im ersten Teii- 

^"^^ - auch Querbeziehungen : 

ubrzgen Hardware erfasst werden kdnnen. 

Vorteilhafterweise ist ein dritter Teiibereich des grafischen 
Anzezgemzttels znr Darstellung mindestens eines Tells der 
Signal, znsbesondere weiterer Werte, vorgesehen. Welters 
Werte konnen beispielswelse Registerwerte sein. 

ITJlZlltZ' r 1±Cher V °" iCht ™^" Hardware-Simulation 
wzrd erlezchtert, wenn gemaB einer vorteilhaf ten Ausgestal- 
tung der Erzindung die Schaltung mit dem Prozessor, dem Pro- 
grammspezcher und den applikationsspezirischen Hardwareklmpo- 
nenten zn ezner Hardware-Beschreibungssprache beschrieben 

Das System lasst sich mit geringem Aurwand an verschiedene 
Prozessoren anpassen, wenn gem 8B einer vorteilhaften Ausges- 
taltung der Erfindung Mittel zum Anpassen des Systems an ver- 
schzedene Prozessortypen vorgesehen sind. 

aeItf^r nd z Wlrd Erflndu "5 a ^and der in den Figuren dar- 

gestellten Ausfahrungsbeispiele naher beschrieben und erlau- 



Es zeigen 
FIG 1 



erne schematische Darstellung eines Systems zur 
Verknupfung und Darstellung von Signalen einer Vor- 
nchtung zur Hardware-Simulation und Elementen ei- 
nes Listings eines Programms, 
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FIG 2 einen Ausschnitt einer Darstellung von Signalen ei- 

ner Vorrichtung zur Hardware-Simulation und 

FIG 3 eine Darstellung von Signalen einer Vorrichtung zur 

Hardware-Simulation und Elementen eines Listings 
exnes Programms. 

FIG 1 zeigt ein System zur Verknupfung und Darstellung von 
Signalen 4, 5 einer Vorrichtung zur Hardware-Simulation 1 und 
Elementen 15 eines Listings 2 eines Programms 3 in schemati- 
scher Darstellung. Die Vorrichtung zur Hardware-Simulation 1 
sxmulxert das Verhalten einer Schaltung 6 mit einem Prozessor 
7, exnem Programmspeicher 8 und applikationsspezif ischen 
Hardwarekomponenten 10. Der Prozessor 7 kann z. B. ein Mikro- 
prozessor oder Mikrocont roller sein. Der Programmspeicher 8 
enthalt den Programmcode 9 des Programms 3. Die Schaltung 6 

HDWHm Hi i f Y iner Ha ^ware-Beschreibun g ssprache, abgekarzt 
HDL (HDL = Hardware Description Language), im Ausf uhrungsbei- 
spxel mittels VHDL (VHDL - Very High Speed Integrated Circuit 
Hardware Description Language) beschrieben. Mit dem Bezugs- 
zexchen 17 wird der Quellcode in VHDL bezeichnet. Die Vor- 
richtung zur Hardware-Simulation 1 wird entsprechend auch als 
HDL-Sxmulator bezeichnet. Ein Beispiel fur einen HDL- 
Srmulator 1st das Produkt "ModelSim" der Firma Model Techno- 
logy, Portland, Oregon, USA. Die Schaltung 6 ist z. B ein 
sogenannter ASIC (ASIC = Application Specific Integrated Cir- 
cuit - Anwendungsspezifische integrierte Schaltung) . Der HDL- 
Quellcode 17 wird mit einem geeigneten Compiler in ein HDL- 
Sxmulator-Format 18 umgewandelt, welches von der Vorrichtung 
zur Hardware-Simulation 1 verarbeitet werden kann. Die Vor- 
richtung zur Hardware-Simulation 1 erzeugt Signale 4, 5 als 
Ergebnis der Simulation. Das Programm 3, bzw. der Programmco- 
de 9 des Programms 3 wird mittels eines Compilers in ein Da- 
tenfile 16 (ublicherweise mit Daten in hexadezimaler Form) 
und ein Listing 2, auch Listfile genannt, umgewandelt. Das 
Lxsting 2 enthalt sowohl die Programmbef ehle als auc h die zu- 
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gehorigen Kommentare. Das Listing 2 ist zeilenweise aufge- 
baut, wobei jede Zeile jeweils einen Programmbef ehl bzw. eine 
Anweisung enthalt, gegebenenf alls mit dem zugehSrigen Kommen- 
tar. Eine Zeile, ein Programmbef ehl, eine Anweisung bzw. ein 
Kommentar sind Elemente 15 des Listings 2. Ein Debugger 19 
verknupft die Elemente 15 des Listings 2 des Programms 3 mit 
den bex der simulierten Ausftihrung des im Programmspeicher 8 
enthaltenen, mit diesen Elementen 15 korrespondierenden Pro- 
grammcodes 9 erzeugten Signalen 4, 5. Die Elemente 15 des 
Listings 2 des Programms 3 werden in einem ersten Teilbereich 
11 des grafischen Anzeigemittels 14 und die Signale 4, 5 in 
emem zweiten Teilbereich 12 bzw. in einem dritten Teilbe- 
reich 13 des Anzeigemittels 14 dargestellt. 

FIG 2 zeigt einen Ausschnitt 30 einer Darstellung von Signa- 
len 4, 5 einer Vorrichtung zur Hardware-Simulation 1. Die 
Signale 4, 5 werden als sogenannte Waveforms 35, 36 und 37 
dargestellt. 



FIG 3 zeigt eine Darstellung 23 von Signalen 4, 5 einer Vor- 
richtung zur Hardware-Simulation 1 und Elementen 15 eines 
Listings 2 eines Programms 3. Die Elemente 15 des Listings 2 
werden in einem ersten Teilbereich 11, die Signale 4, 5 in 
einem zweiten 12 bzw. einem dritten 13 Teilbereich eines An- 
zeigemittels 14 dargestellt. Die Elemente 15 k6nnen mit einer 
Markierung 20, z. B. einer farblichen Kennzeichnung, versehen 
werden. Die Signale 4 konnen mit einer Markierung 21, z B 
einem Cursor, gekennzeichnet werden. Ein Anzeigemittel 14 
kann eine Bildschirmoberf lache sein, die Teilbereiche 11 bis 
13 konnen als Anzeigef enster realisiert sein. Der Ablauf des 
Programms 3 im Prozessor 7 (siehe FIG 1) wird mit Hilfe des 
grafischen Frontends, des Debuggers 19, welcher auf die Sig- 
nale 4, 5 der Vorrichtung zur Hardware-Simulation 1 aufsetzt 
visualisiert. Die Visualisierung des Programmablaufes erfolgi 
durch Zugriff auf Signale des Prozessors 7, deren Werte durch 
die Vorrichtung zur Hardware-Simulation 1 berechnet wurden 
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GemaA dem Ausf uhrungsbeispiel ist der Debugger 19 in der 
Skriptsprache TCL/TK realisiert (TCL/TK = Tool Command Langu- 
age/Toolkxt) und benutzt die TCL/TK-Schnittstelle zu HDL- 

Hnr :e o. en L die HDL - Simulator ~ Verfugung stellt. Solche 

HDL-Obnekte konnen z. B. als Waveforms dargestellt warden. Urn 
den Debugger 19 mOglichst flexibel zu gestalten, d. 



dxesem Zusammenhang, dass er relativ einfach an verschiedene 
Prozessoren angepasst werden kann, wird der Debugger 19 in 
zwei Abschnitte aufgeteilt. Ein erster allgemeiner Teil 
stellt Prozeduren zur Visualisierung bereit . Ein zweiter pro- 
zessorspezifischer Teil ist dem jeweiligen Prozessor anpass- 
bar und setzt sich z. B. aus folgenden Prozeduren zusammen- 

• Prozeduren fur Single-Step rechts/links 

• Prozeduren zum Bestimmen der Registerwerte 

o Prozeduren fur die Kopplung von Signalen und Elementen des 
Listings 

° Prozeduren zur Konf iguration 

in den Prozeduren far Single-Step rechts/links (Bezugszeichen 
22 in FIG 3) wird der Cursor in einem Wavef orm-Fenster auf 

Tr,T hSten gUltigen BSfehl gSSet2t - Ftir d3S Beis P-l eine. 
KRISCS-Prozessors (KRISC8 = Kommunikations-RISC 8 Bit Spezi- 

al-Core fur die Kommunikation in Feldbussystemen der Firma 
Siemens AG, Munchen, Deutschland) ist dies in FIG 2 veran- 
schaulicht. 

Der im Folgenden wiedergegebene Ausschnitt aus einem Listing 
zeigt exne Prozedur far Single-Step-Right. 



8 

# Prozedur fur Single-step-Rig ht 

# ACHTUNG: pc muss im Wave-p.^v 

Proc right__krisc8.Proc {} { 
5 global minideb 

global DEBUG 

set time_no W flindex (getactivecursortime] 0] 
-t address (examine _ tiae $time _ noM $minlde 

set addres S _tmp (examine -time (ex„r s,< " (pc-path, ] 

0 Sminide* , P c-path> , ' ^ $tlme - n ° W + $minideb «»-«*0O> , $minideb (TIME _ DNIT) ^ 

set i 1 

if {$ DEBUG mm "on" I ft - 

on } {echo "anfang von right. Proc") 

if {$address_tmp mm "No^Data"} { 

•mairxFrame .label_ meas age configure h« n- n 

odr.iabel__info configure -text "" 

return 

) 

# Anfang vom naechsten Befehl suchen 

while < $ address « $addres 5 _tmp> { 

if { $ DEBUG "on"; fe ^ A » . 

} (eCh ° "^gnt.Proc: while-schleife 1") 

incr i 

set address.tmp fexamine -time Cexpr $ ti*e now + $i * 6mi • « , 
-hex $minideb < P c- P ath) ] " $minideb (CLK_PERiOD) ] $minideb (Time^jnit) 



} 



set time_now [expr $time now + Si * * m < 

- + 51 $^nideb(CLK_PERlOD)] 

if {$ DEBUG mm n on „ } 

ignc.Proc.time^now — > $ t ime now"} 
set schleife 1 " 

# Suche den naechseten gueltigen Befehl 
while {$schleife 1} { 

if {$DEBDG " " on "> < ech ° "r ighttProC! while _ schleife 2 „, 

# Ende des Befehls suchen 

•t address (examine -time $ time_now *minideb(T IME roiT) _ hex $minid h , 
set address.*,* texamine -time (expr $ time ?minideb (pc-path) ] 

$mi„ideb (pc-path)] »mimdeb(CLK_PERlOD) ] $mi„ideb (TIME_0NIT) -hex 

if ($addres S- tmp "NojData") { 



200308945 



9 

•mainframe. label_ me3 sage configure -bg DimGray -fg red -text "End of Simulation reached." 
set minideb(auto_step_right) 0 

.mainFrame.frame^toolbar.autostep^right configure -background grey -activebackground khaki2 
.mainFrame.frame_toolbar.label_info configure -text 
5 return 

> 

set i 1 

while {$address == $address_tmp} { 

if { $ DEBUG == "on"} {echo "right. Proc: while-Schleif e 3") 
10 incr i 

set address_tmp [examine -time [expr $time_now + $i * $minideb (CLKJPERIOD) ] $mini- 
deb(TIME_UNIT) -hex $minideb (pc-path) ] 
} 

set time_now_tmp [expr $time_now + $i * $minideb (CLK.PERIOD) ] 
15 # Befehl ist 16 Bit breit? 

set instruction [examine -time $time_now $minideb (TIME_UNIT) -hex Sminideb (instruction) ] 

set digit [split $instruction ""] 

set kl "[lindex $digit 0] [lindex $digit 1] " 

if { $ DEBUG ~ "on"} {echo "right. Proc: splitted instruction _> <$kl>"} 

20 if {$ki c= »i E « } { 

# Befehl ist 16 Bit breit, 1 Befehl weitergehen 
if {$ DEBUG — "on"} {echo "right. Proc: 16 Bit Befehl"} 
set time_now $ time_now_tmp 
} else { 

set read_time [expr $time_now_tmp - 0.5 * $minideb (CLKJPERIOD) ] 
if { $ DEBUG = "on"} {echo "right . Proc: time^now -> $time_now; time_now_tm P ~> 
$time_now_tmp; read__time — > $read_time"} 

if {$ DEBUG ~ "on"} {echo "enjipe ~> [examine -time $read_time $minideb (TIME^UNIT) -bin 
Sminideb ( en_pipe ) ] ; \ 

resjpipe — > [expr ! [examine -time $read_time $minideb (TIMEJJNIT) 
-bin $minideb ( res_pipe ) 3 3 " } 

if {[examine -time $read_time $minideb (TIME.UNIT) -bin $minideb<en _pipe)] && I [examine -time 
$read_time $minideb (TIMBJJNIT) -bin $minideb (res_pipe) ] } { 
# naechsten gueltigen Befehl gefunden 
35 S et schleife 0 

} else { 

if { $ DEBUG « "on"} {echo "right. Proc: Der Befehl ist ungueltigl"} 



30 
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# Befehl wird nicht ausgefuehrt, da 

# - pipe enable nicht gesetzt ist 

# - pipe reset gesetzt ist 

# 1 Befehl weiter gehen 
set time_now $time_now__tmp 



) 



} 

set address_int [examine -time $time_now $minideb (TIME_UNIT) -hex $minideb (pc-path) ] 
if {[catch {.$minideb(wave_name) .tree right -value 'h$address_int 1} result] !=0} { 

# Wenn PC nicht markiert ist, deaktiviere Auto-Step und zeige eine Fehlermeldung an 

set mini deb (autc_step__right) 0 

.mainFrame.frame^toolbar.autostep^right configure -background grey -activebackground khaki2 
.mainFrame.frame_toolbar.label_info configure -text 
notice_show "$result \nPlease select pc in the wave-Window!" 

} 

trace. Proc 
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Dabei wird vereinfacht wie folgt vorgegangen (siehe FIG 2) : 

o Zum momentanen Simulations zeitpunkt wird der Wert des Pro- 
grammcounters 36 (p C/ Programmcounter = Programmzahler) 
ermittelt. Der momentan ausgefuhrte Befehl ist in FIG 2 
mit dem Bezugszeichen 31 gekennzeichnet) 

o Der Beginn des nachsten Befehles wird gesucht. Der Cursor 
wird solange um Vielfache der Taktperiode weitergeschoben, 
bis eine Anderung des Programmzahlers auf tritt . 

o Es wird uberpruft, ob der nun erreichte Befehl ausgefilhrt 
wird. 

© Handelt es sich um einen Befehl, welcher nicht ausge- 
fuhrt wird, so wird der ttbernachste Befehl getestet 
(Wiederholung solange, bis ein ausgefuhrter Befehl er- 
reicht ist oder das Simulationsende erreicht ist) . Im 
Beispielsfall gemali FIG 2 sind die nicht ausgef uhrten, 
d. h. ungultigen Befehle mit dem Bezugszeichen 32 ge- 
kennzeichnet . 

o Wird der erreichte Befehl ausgef tthrt, dann wird der Cur- 
sor im Waveform-Fenster (entspricht dem zweiten Teilbe- 
reich 12 des Anzeigemittels 14 gemafi FIG 3) zu diesem 
Zeitpunkt platziert. Im Beispielsfall gemafi FIG 2 ist 
der nachste ausgefuhrte, d. h. gultige Befehl mit dem 
Bezugszeichen 33 gekennzeichnet. 

Die Ermittlung des gtiltigen Befehls erfolgt prozessorspezi- 
fisch. Es genUgt bei modernen Prozessorarchitekturen ubli- 
cherweise nicht, den Programcounter 36 zu verfolgen, sondern 
es sind zusatzliche Signale 4, 5 auszuwerten, die angeben, ob 
der momentane Befehl giiltig ist (z. B. das der Waveform 34 
zugrundeliegende Signal) . Wenn ein gultiger Befehl ermittelt 
wurde, so erfolgt die Markierung 20 des momentan ausgef uhrten 
Befehls im angezeigten Listing im ersten Teilbereich 11 des 
Anzeigemittels 14 und es werden die Registerwerte im dritten 
Teilbereich 13 des Anzeigemittels 14 angezeigt (siehe folgen- 
den Ausschnitt eines Listings). 
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proc trace. Proc {} { 
global progadr_alt 
global minideb 
global DEBUG 

if {$minideb(configure_done) 1} { 

if { $mini deb (curs or_move_enable) == 1} { 
Di sable Cur sorMove . Proc 

} 

# Programmzaehler auslesen 

set timenow [lindex [getactivecursortime] 0] 

# aktuelle Programmadresse lesen 

if { $ DEBUG = "on") {echo "trace. Proc: timenow eingelesen"} 

set progadr [string tolower [examine -time $timenow $minideb(TIME_UNIT) -hex $minideb(pc- 

path) ] ] 

if {$ DEBUG — "on"} {echo "trace. Proc: progadr gelesen <$progadr>"} 

# Programmadresse ist undefiniert (Anfang von der Simulation) ? 
if {![regexp { [0-9a-fA-F] +} $progadr] > { 

set progadr 0 

} 

# gelesenen Programmcounter nit 2 multiplizieren, urn die Programmadresse zu erhalten (bei NIOS) 

# vorangestellte Nullen werden abgeschnitten 

# da mit hex-Zahlen nicht gerechnet werden kann, wird auf eine Dezimalzahl umgerechnet, 

# das Ergebnis mit 2 multipliziert (bei NIOS, 1 bei KRISC) und anschliefiend wieder in eine 

# hex-Zahl konvertiert. 

set progadr_int [hex2int $progadr] 

set progadrjlnt [expr $minideb (adressmultiplikator) *$progadr_int] 
set progadr [int2hex $progadr_int] 

SearchCodeLine . Proc $progadr 
GetRegisterValues_$minideb (mode) . Proc 
set progradr_alt $progadr 
> else ( 
bell 

.mainFrame.label_message configure -bg DimGray -fg red -text "Before tracing you have to configu- 
re the program." 

) 

) 
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Urn den simulierten Ablauf eines Programms 3 auf einem Prozes- 
sor 7 zu verfolgen, gab es bisher keine zuf riedenstellenden 
Moglichkeiten. Die manuelle Verfolgung des Programmablaufes 
anhand der von einem Simulator ausgegebenen Waveform und ei- 
nem Ausdruck eines Listfiles hat den Nachteil, dass bei den 
ublicherweise verwendeten Prozessoren (Pipelines, Caches, 
u. A.) eine Programmverf olgung sehr aufwendig und fehler- 
trachtig wird. Bei einer Verfolgung des Programmablaufes an- 
hand eines Disassemblerausdruckes muss ein Benutzer keine di- 
rekte Auswertung der Waveform vornehmen. Es wird nur eine 
Liste der vom Prozessor bearbeiteten Befehle ausgegeben. So- 
mit fehlt aber der direkte Bezug zum eigentlichen Programm 
und damit werden auch die im Quelltext eingefiigten Kommentare 
nrcht angezeigt. Beim Verwenden eines Debuggers, der auf ein 
abstrahiertes C-Modell aufsetzt, ergeben sich im Wesentlichen 
zwei Nachteile. Zum einen benotigt man ein C-Modell fur den 
eingesetzten Prozessor, welches normalerweise nicht vorliegt 
und somit aufwendig erstellt werden muss. Zum anderen stellt 
das C-Modell des Prozessors eine erneute Beschreibung des 
Prozessors dar und es ist nicht ausgeschlossen, dass der tat- 
sachliche Prozessor ein vom C-Modell abweichendes Verhalten 
aufweist. Da bei dem hier vorgeschlagenen Verfahren kein C- 
Modell fur den Prozessor 7 benStigt wird, ist zum einen ge- 
wahrleistet, dass der gleiche Prozessor 7 simuliert wird, der 
auch in der Schaltung 6 implementiert ist. Zum anderen halt 
sich der Aufwand zum Anpassen des Debuggers 19 an verschiede- 
ne Prozessoren 7 bzw. Prozessortypen in Grenzen. 

Zusammengefasst betrifft die Erfindung somit ein System und 
ein Verfahren zur Verkntipfung und Darstellung von Signalen 4, 
5 einer Vorrichtung zur Hardware-Simulation 1 und Elementen 
15 eines Listings 2 eines Programms 3 sowie ein Fehlersuch- 
werkzeug. Urn eine gemeinsame Darstellung der Signale der Vor- 
richtung zur Hardware-Simulation und der Elemente des Lis- 
tings des Programms zu ermoglichen, wird vorgeschlagen, dass 
die Vorrichtung zur Hardware-Simulation 1 das Verhalten einer 
Schaltung 6 mit einem Prozessor 7, einem Programmspeicher 8, 
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welcher den Programmcode 9 des Programms 3 enthalt, und ap- 
plikationsspezifischen Hardwarekomponenten 10 simuliert und 
Signale 4, 5 als Ergebnis der Simulation erzeugt, dass die E- 
lemente 15 des Listings 2 des Programms 3 mit den bei der si- 
mulierten Ausfuhrung des im Programmspeicher 8 enthaltenen, 
mit diesen Elementen 15 korrespondierenden Programmcodes 9 
erzeugten Signalen 4, 5 verkntipft werden und dass die Elemen- 
te 15 des Listings 2 des Programms 3 in einem ersten Teilbe- 
reich 11 eines grafischen Anzeigemittels 14 und die Signale 
4, 5 in einem zweiten Teilbereich 12 des Anzeigemittels 14 
darstellbar sind. 

Im Folgenden werden der technische Hintergrund der Erfindung 
und verwendete Begriffe naher erlautert. 



Die beschriebenen Schaltungen werden z. B. in sogenannten 
eingebetteten Systemen (gebrauchlicher ist der entsprechende 
englische Begriff "embedded systems") eingesetzt. Beispiele 
fUr Programmiersprachen fur den Einsatz in eingebetteten Sys- 
20 temen sind C, Assembler, C++ und Java. Diesen Sprachen ge- 

meinsam ist der Einsatz eines Compilers, der eine schrittwei- 
se Vorgehensweise bei der Codeentwicklung vorschreibt, die 
sogenannten edit-compile-load-debug Zyklen. Debugger genannte 
Fehlersuchwerkzeuge werden allgemein verwendet, urn Fehler in 
der Software-Programmierung aufzuspiiren. Da die meisten Soft- 
ware-Entwicklungssysteme hierftir eine integrierte Entwick- 
lungsumgebung zur Verfugung stellen, kdnnen Debugger relativ 
einfach den Programmcode verandern und mit Einzelschritten o- 
der gesetzten Kontrollpunkten auf ihrem Zielsystem iiberpru- 
fen. Man kann damit ein Programm kontrolliert ausfuhren, also 
das Programm Zeile fur Zeile ausfuhren und die Werte von Va- 
riablen abfragen und andern. Software Debugger bieten folgen- 
de Basisfunktionen an: 

35 • Einzelschritt-Ausfuhrung von Assembler- und Hochspra- 

chencode 
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o Setzen von Haltepunkten (Breakpoints) an definierten 
Stellen in Hochsprache oder Maschinencode, an denen das 
Programm vorubergehend angehalten wird 
o Anzeigen von Variablenwerten, logischen Ausdrucken, 
5 Speicheradressen und CPU-Registern 

TCL ist eine plattf ormtibergreif ende Script-Programmier- 
sprache. Durch die Kombination aus Textverarbeitungs-, Datei- 
bearbeitungs- und Systemsteuerungsfunktionen ist TCL fur die- 
10 sen Zweck optimiert. EDA-Tools (EDA = Electronic Design Auto- 
mation) verwenden TCL haufig zusammen mit dem Graf ik-Toolkit 
TK, urn eine flexible und plattf ormunabhangige grafische Be- 
nutzeroberflache zu bieten. Hierzu gehort beispielsweise Mo- 
delSim. 



15 



20 



30 



Im Bereich der eingebetteten Systeme hat der parallele Ent- 
wurf von Hardware und Software den klassischen, rein sequen- 
tiellen Entwurf sablauf weitgehend abgelost. Eingebettete Sys- 
teme spielen eine dominierende Rolle in der Automatisierungs- 
technik. Basis ihres Erfolgs ist die exponentiell steigende 
Komplexitat integrierter Schaltungen und die damit wachsenden 
Moglichkeiten far neue Systemf unktionen, die zunehmend in 
Software realisiert werden. Die daraus resultierende System- 
komplexitat verlangt bei gleichzeitig absinkenden Entwick- 
lungszeiten eine drastische ErhOhung der Entwurf sproduktivi- 
tat. Diese ErhOhung ist nur durch Entwurf sautomation und sys- 
tematische Wiederverwendung von Systemf unktionen erreichbar. 
Ein wesentlicher Schritt ist die Integration von Hardware- 
und Softwareentwurf, der Hardware/Sof tware-Coentwurf . 



Hardware- und Softwareentwurf beginnen oft vor der Vollendung 
der Systemarchitektur oder gar vor der endgtlltigen Festlegung 
der Spezifikation. Systemarchitekten, Anwender und Kunden o- 
der Marketingexperten entwickeln gemeinsam Anf orderungsdef i- 
35 nition und Spezifikation. Der Systemarchitekt entwickelt dar- 
aus ein System kooperierender Systemf unktionen als Grundlage 
eines anschliefienden, parallelen Entwurfs von Hardware und 
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Software. An dieser Stelle wird auch die Grobarchitektur der 
Zielhardware festgelegt. Der Hardware-/Sof tware-Schnitt- 
stellenentwurf erfordert eine Beteiligung von Hardware- und 
Softwareentwicklern. Die Integration der Hardware und Soft- 
warekomponenten und der Test des integrierten Systems folgt 
als letzter Schritt. In alien Phasen fuhren Abweichungen von 
erwarteten Entwurf sergebnissen oder Anderungen der Spezifika- 
tion zu einer Wiederholung von Entwurf sschritten. Ein zentra- 
les Problem im Entwurf sprozess ist die Oberwachung und Integ- 
ration des parallelen Hardware- und Sof tware-Entwurf s . Eine 
friihe Fehlererkennung erfordert die Kontrolle von Konsistenz 
und Korrektheit, die urn so aufwendiger wird, je detaillierter 
der Entwurf ausgearbeitet ist. 

Bei der Hardware-Software Cosimulation wird die Ausfuhrung 
der Software auf der (Prozessor-) Hardware zusammen mit appli- 
kationsspezifischen Hardwarekomponenten simuliert. Da eine 
Simulation mit hohem Detaillierungsgrad, wie er im Hardware- 
entwurf iiblich ist, zu langsam fur eine praktisch nutzbare 
Softwaresimulation ist, werden tiblicherweise abstrakte Pro- 
zessormodelle benStigt. Zu diesem Zweck werden die Prozesso- 
ren abstrakter ("auf einer hoheren Abstraktionsebene" ) model- 
liert als die anderen Hardwarekomponenten. Dabei wird das 
Zeitverhalten des Prozessors nicht mehr taktgenau, d. h. fur 
jeden Taktzyklus auf geschliisselt , dargestellt, sondern nur 
noch die Programme mit ihren Ein- und Ausgaben. Das Problem 
der Cosimulation liegt nun in der Kopplung der unterschied- 
lich abstrakten Modelle, derart dass eine hinreichende Genau- 
igkeit der Simulation erreicht wird. Im ungunstigsten Fall 
greifen Prozessor und andere Hardwarekomponenten auf den 
gleichen Speicher zu. Eine genaue Modellierung erfordert in 
diesem Fall angepasste Speicher- und Busmodelle und spezielle 
Simulationstechniken. Ein Beispiel hierfilr bietet der Cosimu- 
lator Seamless CVS der Firma Mentor Graphics, Wilsonville, O- 
regon, USA. Das Produkt Seamless CVS benutzt ein abstraktes 
Prozessormodell, das die Bef ehlsausftihrung nachbildet (ein 
sogenannter Instruction Set Simulator) . Fur den Speicher- 
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zugriff werden Busmodelle verwendet, deren Abstraktion abhan- 
gig vom gleichzeitigen Zugriff von Prozessor und Hardware 
ist. Speicher, auf die lediglich der Prozessor zugreift, wer- 
den folglich abstrakter modelliert als solche, in denen Kon- 
5 flikte auftreten kSnnen. Voraussetzung ist also die Verfiig- 
barkeit einer Bibliothek von Modellen, die vom CAD-Anbieter 
Oder dem Prozessorhersteller bezogen wird. 

Ein abstrakterer Ansatz reduziert das Prozessormodell auf die 
10 reine Programmausfuhrung auf dem PC oder der Workstation und 
modelliert lediglich das Interface mit Zeitverhalten . Die 
Kopplung der Sof tware-Ausf uhrung zum Hardwaremodell erfolgt 
dann iiber ein simulatorspezif isches Kommunikationsprotokoll, 
das der Entwickler in die Software einfugen muss. Fur diese 
15 Modellierung sind nur Interf ace-Modelle erf orderlich, was die 
Bibliotheksproblematik wesentlich vereinf acht . Andererseits 
wird das Zeitverhalten nur auf der Hardwareseite korrekt mo- 
delliert. Beispiel fur einen solchen Cosimulator ist das Pro- 
dukt Eagle der Firma Synopsys, Mountain View, Kalifornien, 
20 USA. 
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Patentanspriiche 
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1. System zur Verkniipf ung und Darstellung von Signalen (4, 5) 
einer Vorrichtung zur Hardware-Simulation (1) und Elementen 
(15) eines Listings (2) eines Programms (3), 

o wobei die Vorrichtung zur Hardware-Simulation (1) das Ver- 
halten einer Schaltung (6) mit einem Prozessor (7), einem 
Programmspeicher (8), welcher den Programmcode (9) des 
Programms (3) enthalt, und applikationsspezif ischen Hard- 
ware komponent en (10) simuliert und Signale (4, 5) als Er- 
gebnis der Simulation erzeugt, 

o wobei die Elemente (15) des Listings (2) des Programms (3) 
mit den bei der simulierten Ausfuhrung des im Programm- 
speicher (8) enthaltenen, mit diesen Elementen (15) kor- 
respondierenden Programmcodes (9) erzeugten Signalen (4, 
5) verkniipf t werden, 

o wobei die Elemente (15) des Listings (2) des Programms (3) 
in einem ersten Teilbereich (11) eines grafischen Anzeige- 
mittels (14) und die Signale (4, 5) in einem zweiten Teil- 
bereich (12) des Anzeigemittels (14) darstellbar sind. 

2. System nach Anspruch 1, 

dadurch gekennzeichnet, 
dass eine Markierung (20) eines Elements (15) des Listings 
(2) des Programms (3) im ersten Teilbereich (11) des grafi- 
schen Anzeigemittels (14) und eine Markierung (21) der mit 
diesem Element (15) verkniipften Signale (4, 5) im zweiten 
Teilbereich (12) des Anzeigemittels (14) vorgesehen ist. 

3. System nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

dass ein dritter Teilbereich (13) des grafischen Anzeigemit- 
tels (14) zur Darstellung mindestens eines Teils der Signale 
(4, 5) vorgesehen ist. 

4. System nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 
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dass die Schaltung (6) mit dem Prozessor (7), dem Programm- 
speicher (8) und den applikationsspezif ischen Hardware kompo- 
nenten (9) in einer Hardware-Beschreibungssprache beschrieben 
sind. 



5. System nach einem der vorhergehenden Ansprtiche, 
dadurch gekennzeichnet, 

dass Mittel zum Anpassen des Systems an verschiedene Prozes- 
sortypen vorgesehen sind. 

6. Verfahren zur Verkntipfung und Darstellung von Signalen 

(4, 5) einer Vorrichtung zur Hardware-Simulation (1) und Ele- 
menten (15) eines Listings (2) eines Programms (3), 

• wobei die Vorrichtung zur Hardware- Simulation (1) das Ver- 
halten einer Schaltung (6) mit einem Prozessor (7), einem 
Programmspeicher (8), welcher den Programmcode (9) des 
Programms (3) enthalt, und applikationsspezif ischen Hard- 
ware komponent en (10) simuliert und Signale (4, 5) als Er- 
gebnis der Simulation erzeugt, 

• wobei die Elemente (15) des Listings (2) des Programms (3) 
mit den bei der simulierten Ausfuhrung des im Programm- 
speicher (8) enthaltenen, mit diesen Elementen (15) kor- 
respondierenden Programmcodes (9) erzeugten Signalen (4, 
5) verknupft werden, 

o wobei die Elemente (15) des Listings (2) des Programms (3) 
in einem ersten Teilbereich (11) eines graf ischen Anzeige- 
mittels (14) und die Signale (4, 5) in einem zweiten Teil- 
bereich (12) des Anzeigemittels (14) dargestellt werden. 

7. Verfahren nach Anspruch 6, 

dadurch gekennzeichnet, 

dass ein Element (15) des Listings (2) des Programms (3) im 

ersten Teilbereich (11) des grafischen Anzeigemittels (14) 

und die mit diesem Element (15) verkntipften Signale (4, 5) im 

zweiten Teilbereich (12) des Anzeigemittels (14) markiert 

werden. 
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8. Verfahren nach Anspruch 6 Oder 7 , 
dadurch gekennzeichnet, 

dass in einem dritten Teilbereich (13) des grafischen Anzei- 
gemittels (14) mindestens ein Teil der Signale (4, 5) darge- 
stellt wird. 

9. Verfahren nach einem der Ansprttche 6 bis 8, 

dadurch gekennzeichnet, 

dass die Schaltung (6) mit dem Prozessor (7), dem Programm- 

speicher (8) und den applikationsspezif ischen Hardware kompo- 

nenten (9) in einer Hardware-Beschreibungssprache beschrieben 
sind. 

10. Verfahren nach einem der Anspriiche 6 bis 9, 
15 dadurch gekennzeichnet, 

dass das Verfahren an verschiedene Prozessortypen anpassbar 
ist . 



10 



20 



• 



11. Fehlersuchwerkzeug zur Verknupfung und Darstellung von 
Signalen (4, 5) einer Vorrichtung zur Hardware-Simulation (1) 
und Elementen (15) eines Listings (2) eines Programms (3), 
o wobei die Vorrichtung zur Hardware-Simulation (1) das Ver- 
halten einer Schaltung (6) mit einem Prozessor (7), einem 
Programmspeicher (8), welcher den Programmcode (9) des 
Programms (3) enthalt, und applikationsspezif ischen Hard- 
warekomponenten (10) simuliert und Signale (4, 5) als Er- 
gebnis der Simulation erzeugt, 
• wobei das Fehlersuchwerkzeug Mittel zur Verknupfung der E- 
lemente (15) des Listings (2) des Programms (3) mit den 
bei der simulierten Ausfiihrung des im Programmspeicher (8) 
enthaltenen, mit diesen Elementen (15) korrespondierenden 
Programmcodes (9) erzeugten Signalen (4, 5) aufweist, 
wobei die Elemente (15) des Listings (2) des Programms (3) in 
einem ersten Teilbereich (11) eines grafischen Anzeigemittels 
35 (14) und die Signale (4, 5) in einem zweiten Teilbereich (12) 
des Anzeigemittels (14) darstellbar sind. 
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Z u s airmen f a s s ung 



Verknupfung und Darstellung von Signalen einer Vorrichtung 
zur Hardware-Simulation und Elementen eines Listings eines 
Programms 

Die Erfindung betrifft ein System und ein Verfahren zur Ver- 
knupfung und Darstellung von Signalen (4, 5) einer Vorrich- 
tung zur Hardware-Simulation (1) und Elementen (15) eines 
Listings (2) eines Programms (3) sowie ein Fehlersuchwerk- 
zeug. Urn eine gemeinsame Darstellung der Signale der Vorrich- 
tung zur Hardware-Simulation und der Elemente des Listings 
des Programms zu ermoglichen, wird vorgeschlagen, dass die 
Vorrichtung zur Hardware-Simulation (1) das Verhalten einer 
Schaltung (6) mit einem Prozessor (7), einem Programmspeicher 
(8), welcher den Programmcode (9) des Programms (3) enthalt, 
und applikationsspezifischen Hardware komponent en (10) simu- 
liert und Signale (4, 5) als Ergebnis der Simulation erzeugt, 
dass die Elemente (15) des Listings (2) des Programms (3) mit 
den bei der simulierten Ausfuhrung des im Programmspeicher 
(8) enthaltenen, mit diesen Elementen (15) korrespondierenden 
Programmcodes (9) erzeugten Signalen (4, 5) verknupft werden 
und dass die Elemente (15) des Listings (2) des Programms (3) 
in einem ersten Teilbereich (11) eines grafischen Anzeigemit- 
tels (14) und die Signale (4, 5) in einem zweiten Teilbereich 
(12) des Anzeigemittels (14) darstellbar sind. 



FIG 1 




FIG 2 



200308945 

3/3 



23 20 




